The configuration of software applications is a very complex task. A typical scenario is the definition of the security requirements for the correct operation of the software applications.
For example, the software applications may be written in the Java language. Java applications run in a Java Virtual Machine (JVM), which consists of an abstract computing machine providing a runtime environment independent of the underlying (hardware and software) platform. This allows running the Java applications virtually on any type of computers (provided that the required JVM is available). For this reason, the Java applications have found extensive use in the Internet. Whenever a Java application must execute a specific operation on a secured resource (for example, reading or writing a file), a corresponding permission must be granted for that operation. In the Java environment, all the available permissions are defined in a so-called policy file (or more). Therefore, when a new Java application (or a new version thereof) is deployed it is necessary to ensure that the permissions required for its correct operation are defined in the policy file.
However, the composition of the policy file is decidedly not trivial. Indeed, for this purpose an operator must add a specific entry to the policy file for each required permission (according to the corresponding syntax).
Some graphical tools (such as the “policytool” shipped with the JSDK) are available to facilitate the task of editing the policy file—without the need of knowing its syntax.
In any case, this task remains substantially manual (and then strongly dependent on the skill of the operator and prone to errors).
Moreover, it is very difficult (if not impossible) to identify all the permissions required by the Java application a priori. Therefore, it may happen that some permissions are missing; in this case, when an operation requiring a missing permission is invoked at run-time a corresponding exception is thrown. Typically, this exception reaches a bottom of an execution stack (since it cannot be managed within the Java application itself), thereby causing a malfunctioning in the whole Java application. The operator must then stop the Java application, add the missing permission to the policy file, and then restart the Java application.
However, the above-described “trial and error” approach is very time consuming. Moreover, this has a deleterious effect on the reliability of the Java application.
U.S. Pat. No. 6,526,513 discloses a solution for managing the permissions dynamically. In this case, when a Java application requires a permission that is not defined in the policy file, a user is prompted to grant or deny the required permission at run-time; the granted or denied permissions may also be saved so as to take effect across different sessions. The cited document further introduces the concept of denied permissions in the policy file, so as to allow granting permissions to large collections of secured resources with the exception of a few of them.
However, the proposed technique requires the definition of a custom security manager (in place of the standard one that is used to manage the permissions in the Java environment). In any case, the problem of defining the bulk of the permissions statically in the policy file remains unresolved (with the same drawbacks pointed out above).